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(54) Achromatic lighting in a graphics system and method 



(57) A graphics system (50) including a custom 
graphics and audio processor (114) produces exciting 
2D and 3D graphics and surround sound. The system 
(50) includes a graphics and audio processor (114) in- 
cluding a 3D graphics pipeline (1 80) and an audio digital 
signal processor (156). Cartoon lighting and other non- 
photorealistic effects can be produced by using a light- 
ing calculation to produce a parameter other than color 
or opacity for use in a later modification of a color or 
opacity value. In more detail, the example embodiment 



uses the lighting calculation to generate texture coordi- 
nates used in a texture mapping operation (700a). The 
texture mapping operation (700a) allows lighting com- 
putation results to select between brush strokes for car- 
toon lighting and other effects. The resulting dynamic 
cartoon lighting animation can be performed on a low 
cost platform such as a home video game system or per- 
sonal computer. 
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Description 
Field of the Invention 



distance or angle that is applied to a further function (e.g., texturing). 
Background And Summary Of The Invention 
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[0008] The present invention provides improvements in non-photorealistic and other imaging effects that can be 
implemented using a low cost graphics system such as, for example, a home video game platform or a personal 
computer graphics accelerator. 

[0009] In accordance with one aspect provided by this invention, the lighting function of the type typically used to 
light objects within a scene is used to produce a parameter other than color. Such a parameter is used to modify a 
color or opacity of an object. 

[0010] In accordance with another aspect provided by this invention, a lighting calculation performs per-vertex lighting 
to provide conventional color component outputs. The color component outputs are applied to a texturing function that 
processes the color components as achromatic parameters. The texturing function output provides a visualization 
effect (e.g., color and/or opacity modified based on the achromatic parameters) that is used to contribute to the visu- 
alization of a rendered scene. 

[0011] In accordance with yet another aspect provided by this invention, the lighting calculation output provides three 
color components one of which is discarded. The other two color components are converted into texture coordinates 
and used in a texture mapping operation. One of the texture coordinates selects a one-dimensional texture map within 
a two-dimensional table. The other texture coordinate selects a particular texel within the selected one-dimensional 
texture map The resulting selected texel provides color and/or alpha information that is applied to a surface defined 
by the vertex 

[0012] In accordance with yet another aspect provided by this invention, non-photorealistic cartoon lighting effects 
are provided m h r eni time 3D gr nphes system by using a lighting calculation to produce a parameter other than color 
or opacity A cric-UirtufivuriH te*tuiu map can be defined specifying different brush strokes as a function of the pa- 
rameter. A convent on^i tc ■! uf c rr apomg operation can be used to map the one-dimensional texture map onto a polygon 
surface based on tnc p*r,«-nctcf 

[0013] In more ocm.i ?*c d*&c*osed system can provide conventional lighting-based shading (as discussed above) 
as part of its ovcr.iii opc* .it t>u p-ov des an additional enhancement that allows the lighting equation(s) to generate 
a texture coordm^c i . c « p.«'.«?rx>tor other than color or opacity). That other parameter may be inputted to a further 
function (e.g. a kx*up i-*t-H? itcod hs a texture) to provide a further result - which may in turn change the color/ 
opacity of an cbje<rt T .mcrm^tc step of, having the lighting calculation produce a parameter that only indirectly 
affects color anovnr .xwrfy n - h ri««ouyed object provides additional flexibility beyond conventional approaches that 
use the lighting equ^t'ori o»;fput to orcctly affect primitive surface color 

[0014] A particuMi cinn-pic enoodiment uses the lighting equation result to select a one-dimensional texture from 
a number of textures As an ciamp e. to display a tree trunk you might define two different one-dimensional textures 
- one having a range of silvers and the other having a range of browns. The lighting equation could be used to determine 
the angle at which a iiqht source is striking the tree trunk, with the result selecting between the two textures. The tree 
trunk could be colored (usng conventional texture mapping) with a range of different silvers from an oblique angle but 
with a range of browns/blacks when the light is striking it head-on. In such a case, the lighting equation selects a one- 
dimensional texture (i c it is acting as a parameter other than color or opacity - in this particular example, selecting 
between two different textures) 

[0015] In the particular embodiment disclosed herein, improvements are made to the transformation and lighting (T 
& L") pipeline to allow it to generate a texture coordinate(s) based on the lighting equation. The transformation and 
lighting develops the lighting equation output but instead of providing it directly to change the pixel color/opacity gen- 
erated by the rasterizer it provides the result as a texture coordinate to a texture unit. In the disclosed embodiment, 
the output of the texture unit is a color or opacity that is blended with the objects primitive color/opacity (e.g., as 
developed by transform and lighting pipeline and the rasterizer in a conventional fashion based on the same or different 
lighting equation using a conventional shading algorithm such as Gouraud or Phong shading) to provide a modified 
color/opacity value for display 

Brief Description Of The Drawings 

[0016] These and other features and advantages provided by the invention will be better and more completely un- 
derstood by referring to the following detailed description of presently preferred embodiments in conjunction with the 
drawings of which: 

Figure 1 is an overall view of an example interactive computer graphics system; 

Figure 2 is a block diagram of the Figure 1 example computer graphics system; 

Figure 3 is a block diagram of the example graphics and audio processor shown in Figure 2; 

Figure 4 is a block diagram of the example 3D graphics processor shown in Figure 3; 

Figure 5 is an example logical flow diagram of the Figure 4 graphics and audio processor; 

Figure 6 shows an example high-level image generating process provided by this invention; 
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Figure 7 shows a more specific image generating process provided by this invention that uses texturing based on 

an achromatic lighting parameter; 

Figure 8A shows an example texture function; 

Figure 8B shows an example one-dimensional texture map; 
5 Figure 9 shows an example texture mapping procedure; 

Figure 10A shows an example two-dimensional texture map; 

Figure 10B shows a further example two-dimensional texture map; 

Figure 11 shows an example lighting pipeline implementation; 

Figure 12 shows an example association of lights with color channels; 
10 Figure 13 shows an example transform unit implementation; 

Figure 14 shows an example lighting pipeline implementation; 

Figure 15 shows an example vector dot/add unit implementation; 

Figure 16 shows an example normalizer implementation; 

Figure 17 shows an example distance attenuator implementation; 
is Figure 1 8 shows an example light scaler implementation; 

Figure 19 shows an example integer accumulator implementation; 

Figure 20 shows an example state transition diagram; and 

Figures 21 A and 21 B show example alternative compatible implementations. 

20 Detailed Description Of Example Embo diments Of The Invention 

[0017] Figure 1 shows an example interactive 3D computer graphics system 50. System 50 can be used to play 
merPctive L video games with interesting stereo sound. It can also be used for a variety of other «PP^^. 



35 



40 



svstem 50 can interactively change the viewpoint in response to real time inputs from handheld controllers 52a, £2D 
SZr^TdSL. This allows" the game player to see the world through the eyes of someone within or outside ■« 
L world Svstem 50 can be used for applications that do not require real time 3D interactive display (e g. , 2D display 
non " teractive display), but the capability of displaying quality 3D images very quickly can be used 
30 to create very realistic and exciting game play or other graphical interactions 

r0019l To play a video game or other application using system 50, the userf.rst connects a main unrt 54 to h« or her 
Sr television set 56 or other display device by connecting a cable 58 between the two. Mam unrt 54 produces both 
%E£Z?£S£Z** for controlling co.or te.evision set 56. The video signals are what control Jh. .mages 
displayed on the television screen 59, and the audio signals are played back as sound through televis.on stereo loud- 

Sr S T?e L uslr R a te o needs to connect main unit 54 to a power source. This power source may be a conventional 
AC adapter (not shown) that plugs into a standard home electrical wall socket and converts the house current into a 
lower DC voltage signa suitable for powering the main unit 54. Batteries could be used in 

r0021 1 The u ser may use hand controllers 52a. 52b to control main unit 54. Controls 60 can be used, for example 
to speU^he direcZ ?up or down, left or right, closer or further away) that a character displayed on television 56 
shoSw Ivl wihTn a 3D world. Controls 60 also provide input for other applications (e.g., menu selection pointer/ 
o^or confrol etc ) Controllers 52 can take a variety of forms. In this example, controllers 52 shown each include 
contro.; Teo ^uch as joysticks, push buttons and/or directional switches. Controllers 52 may be connected to mam unrt 
54 by cables or wirelessly via electromagnetic (e.g., radio or infrared) waves. 
45 [0022] To play an application such as a game, the user selects an appropriate storage medium 62 ^onng the video 
gSS 'or other application he or she wants to play, and inserts that storage medium 

Storaoe medium 62 may, for example, be a specially encoded and/or encrypted optical and/or magnetic disk. The user 
may o 9 pJSe a poweTswrtch 66 to'turn on main unrt 54 and cause the main unrt to begin running the video , game or 
other application based on the software stored in the storage medium 62. The user may operate controller, 52 to 
so pmv demp"! to main unit 54. For example, operating a control 60 may cause the game or other app.^or £ start 
Mov inq other controls 60 can cause animated characters to move in different directions or change the user's po.nt of 
view in a 3D woriTDepending upon the particular software stored within the storage medium 62. the various controls 
60 on the controller 52 can perform different functions at different times. 

55 Example Electronics of Overall System 

[0023] Figure 2 shows a block diagram of example components of system 50. The primary components include: 
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• a main processor (CPU) 110, 

• a main memory 112, and 

• a graphics and audio processor 114. 

5 [0024] In this example, main processor 110 (e.g. : an enhanced IBM Power PC 750) receives inputs from handheld 
controllers 108 (and/or other input devices) via graphics and audio processor 114. Main processor 110 interactively 
responds to user inputs, and executes a video game or other program supplied, for example, by external storage media 
62 via a mass storage access device 1 06 such as an optical disk drive. As one example, in the context of video game 
play, main processor 110 can perform collision detection and animation processing in addition to a variety of interactive 

10 and control functions. 

[0025] In this example, main processor 1 1 0 generates 3D graphics and audio commands and sends them to graphics 
and audio processor 114. The graphics and audio processor 114 processes these commands to generate interesting 
visual images on display 59 and interesting stereo sound on stereo loudspeakers 61 R, 61 L or other suitable sound- 
generating devices. 

15 [0026] Example system 50 includes a video encoder 1 20 that receives image signals from graphics and audio proc- 
essor 114 and converts the image signals into analog and/or digital video signals suitable for display on a standard 
display device such as a computer monitor or home color television set 56. System 50 also includes an audio codec 
(compressor/decompressor) 122 that compresses and decompresses digitized audio signals and may also convert 
between digital and analog audio signaling formats as needed. Audio codec 122 can receive audio inputs via a buffer 

20 124 and provide them to graphics and audio processor 114 for processing (e.g., mixing with other audio signals the 
processor generates and/or receives via a streaming audio output of mass storage access device 106). Graphics and 
audio processor 114 in this example can store audio related information in an audio memory 126 that is available for 
audio tasks. Graphics and audio processor 114 provides the resulting audio output signals to audio codec 122 for 
decompression and conversion to analog signals (e.g., via buffer amplifiers 128L, 128R) so they can be reproduced 

25 by loudspeakers 61 L, 61 R. 

[0027] Graphics and audio processor 114 has the ability to communicate with various additional devices that may 
be present within system 50. For example, a parallel digital bus 130 may be used to communicate with mass storage 
access device 1 06 and/or other components. A serial peripheral bus 1 32 may communicate with a variety of peripheral 
or other devices including, for example: 

30 

• a programmable read-only memory and/or real time clock 134, 

• a modem 1 36 or other networking interface (which may in turn connect system 50 to a telecommunications network 
1 38 such as the Internet or other digital network from/to which program instructions and/or data can be downloaded 
or uploaded), and 

35 • flash memory 140. 

A further external serial bus 1 42 may be used to communicate with additional expansion memory 1 44 (e.g., a memory 
card) or other devices. Connectors may be used to connect various devices to busses 130, 132, 142. 

40 Example Graphics And Audio Processor 

[0028] Figure 3 is a block diagram of an example graphics and audio processor 114. Graphics and audio processor 
114 in one example may be a single-chip ASIC (application specific integrated circuit). In this example, graphics and 
audio processor 114 includes: 

45 

• a processor interface 1 50, 

• a memory interface/controller 152, 

• a 3D graphics processor 154, 

• an audio digital signal processor (DSP) 156, 
50 • an audio memory interface 158, 

• an audio interface and mixer 160, 

• a peripheral controller 162, and 

• a display controller 1 64. 

55 [0029] 3D graphics processor 1 54 performs graphics processing tasks. Audio digital signal processor 1 56 performs 
audio processing tasks. Display controller 1 64 accesses image information from main memory 112 and provides it to 
video encoder 120 for display on display device 56. Audio interface and mixer 160 interfaces with audio codec 122, 
and can also mix audio from different sources (e.g., streaming audio from mass storage access device 106, the output 
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of audio DSP 156, and external audio input received via audio codec 122). Processor interface 150 provides a data 
and control interface between main processor 110 and graphics and audio processor 114. 

[0030] Memory interface 152 provides a data and control interface between graphics and audio processor 114 and 
memory 1 1 2. In this example, main processor 1 1 0 accesses main memory 1 1 2 via processor interface 1 50 and memory 
interface 152 that are part of graphics and audio processor 114. Peripheral controller 1 62 provides a data and control 
interface between graphics and audio processor 114 and the various peripherals mentioned above. Audio memory 
interface 158 provides an interface with audio memory 126. 

Example Graphics Pipeline 



[0031] Figure 4 shows a more detailed view of an example 3D graphics processor 154. 3D graphics processor 154 
includes, among other things, a command processor 200 and a 3D graphics pipeline 1 80. Main processor 110 com- 
municates streams of data (e.g., graphics command streams and display lists) to command processor 200. Main proc- 
essor 1 10 has a two-level cache 11 5 to minimize memory latency, and also has a write-gathering buffer 111 for uncached 
is data streams targeted lor the graphics and audio processor 114. The write-gathering buffer 111 collects partial cache 
lines into full cache hncs and sends the data out to the graphics and audio processor 114 one cache line at a time for 
maximum bus usage 

[0032] Command processor 200 receives display commands from main processor 1 1 0 and parses them ~ obtaining 
any addition*! dnin necessary to process them from shared memory 112. The command processor 200 provides a 
20 stream of vertex curwn*ruib to graphics pipeline 180 for 2D and/or 3D processing and rendering. Graphics pipeline 
1 80 generates irrvnqes tascd on these commands. The resulting image information may be transferred to main memory 
112 for access by a-spuy cortro k?* v»oco interface unit 164 - which displays the frame buffer output of pipeline 180 
on display 56 

[0033] Figure 5c.« »oq»oi! ov*Qram of graphics processor 1 54. Main processor 110 may store graphics command 
25 streams 210. ditp».«v us r^: vonox arrays 214 in main memory 112, and pass pointers to command processor 
200 via bus interlace i±C Trx? r^.n p'ocessor 110 stores graphics commands in one or more graphics first-in-first- 
out (FIFO) buffers ?tc <t ^jvoc^ics main memory 110. The command processor 200 fetches: 

• command streams f'rvn rvm memory 112 via an on-chip FIFO memory buffer 216 that receives and buffers the 
30 graphics commands for syncruont/ation/flow control and load balancing, 

• display lists 212 from mnm memory 112 via an on-chip call FIFO memory buffer 21 8, and 

• vertex attributes from tnc command stream and/or from vertex arrays 214 in main memory 112 via a vertex cache 
220. 

35 [0034] Command processor 2C0 performs command processing operations 200a that convert attribute types to float- 
ing point format, and pass the resulting complete vertex polygon data to graphics pipeline 1 80 for rendering/rasteriza- 
tion. A programmable memory arbitration circuitry 130 (see Figure 4) arbitrates access to shared main memory 112 
between graphics pipeline 180 command processor 200 and display controller/video interface unit 164. 
[0035] Figure 4 shows that graphics pipeline 1 80 may include: 

40 

• a transform unit 300. 

• a setup/rasterizer 400 

• a texture unit 500. 

• a texture environment unit 600, and 
45 • a pixel engine 700. 

[0036] Transform unit 300 performs a variety of 2D and 3D transform and other operations 300a (see Figure 5). 
Transform unit 300 may include one or more matrix memories 300b for storing matrices used in transformation process- 
ing 300a. Transform unit 300 transforms incoming geometry per vertex from object space to screen space; and trans- 
50 forms incoming texture coordinates and computes projective texture coordinates (300c). Transform unit 300 may also 
perform polygon clipping/culling 300d. Lighting processing 300e also performed by transform unit 300b provides per 
vertex lighting computations for up to eight independent lights in one example embodiment. Transform unit 300 can 
also perform texture coordinate generation (300c) for embossed type bump mapping effects, as well as polygon clip- 
ping/culling operations (300d). 

55 [0037] Setup/rasterizer 400 includes a setup unit which receives vertex data from transform unit 300 and sends 
triangle setup information to one or more rasterizer units (400b) performing edge rasterization, texture coordinate 
rasterization and color rasterization 

[0038] Texture unit 500 (which may include an on-chip texture memory (TMEM) 502) performs various tasks related 
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to texturing including for example: 

• retrieving textures 504 from main memory 112, 

• texture processing (500a) including, for example, mutti-texture handling, post-cache texture decompression, tex- 
5 ture filtering, embossing, shadows and lighting through the use of projective textures, and BLIT with alpha trans- 
parency and depth, 

• bump map processing for computing texture coordinate displacements for bump mapping, pseudo texture and 
texture tiling effects (500b), and 

• indirect texture processing (500c). 

10 

[0039] Texture unit 500 outputs filtered texture values to the texture environment unit 600 for texture environment 
processing (600a). Texture environment unit 600 blends polygon and texture color/alpha/depth, and can also perform 
texture fog processing (600b) to achieve inverse range based fog effects. Texture environment unit 600 can provide 
multiple stages to perform a variety of other interesting environment-related functions based for example on color/ 

15 alpha modulation, embossing, detail texturing, texture swapping, clamping, and depth blending. 

[0040] Pixel engine 700 performs depth (z) compare (700a) and pixel blending (700b). In this example, pixel engine 
700 stores data into an embedded (on-chip) frame buffer memory 702. Graphics pipeline 1 80 may include one or more 
embedded DRAM memories 702 to store frame buffer and/or texture information locally. Z compares 700a' can also 
be performed al an earlier stage in the graphics pipeline 180 depending on the rendering mode currently in effect (e. 

20 g / compares can be performed earlier if alpha blending is not required). The pixel engine 700 includes a copy op- 
eration 700c that periodically writes on-chip frame buffer 702 to main memory 1 1 2 for access by display/video interface 
unt 164 This copy operation 700c can also be used to copy embedded frame buffer 702 contents to textures in the 
m nn memory 112 for dynamic texture synthesis effects. Anti-aliasing and other filtering can be performed during the 
ccpy ou: operation The frame buffer output of graphics pipeline 180 (which is ultimately stored in main memory 112) 
,r rc „d each frame by display/video interface unit 164. Display controller/video interface 164 provides digital RGB pixel 
values for display or display 102. 

Ein mpkp Achromatic Lighting Function 

jo [0041 1 A< a»i>cussed above, transform unit 300 in the example embodiment performs lighting in addition to geometric 
I'H-.sforffMt.oris c^poing. culling and other functions. In the example embodiment, transform unit 300 supports lighting 
■r "jh*,ve as h per vertex calculation. This means that a color (RGB) value can be computed for every lit vertex, and 
t*. i- :ncso co*or s> can be linearly interpolated over the surface of each lit triangle. This is known as Gouraud shading. 
A**:iorw oceans concerning an example lighting implementation are discussed below in connection with Figures 12 

(0042) t no nn-ncHc embodiment transform unit 300 provides an additional use for lighting function(s) 302 not avail- 
^ ic n t ,ic*!>orM! graphics systems. Generally, the output of the lighting function in the traditional graphics system is 
a ceo' u5>eo f:>? poryqon shading. Some graphics systems provide an alpha (e.g., transparency) value based on a 
. r • i-nct.cn n tne example embodiment provided by the present invention, a lighting function is used to provide 

40 r%r rtcnrorrwK: parameter (i.e.. neither color nor alpha, but something else) used to subsequently modify a color and/ 
or otvicry 

(0043) F «qufc 6 ts a block diagram showing such an arrangement where lighting function 302 provides an achromatic 
parameter used Dy a suosequent process 304 to modify a color or opacity. The results of the modification are displayed 
or a aispia* ocv»rc such as display 56. In this context, the term "lighting function" generally means a mathematical 

<o fu-»cion of a surface position, a surface orientation, an eye location and, in some cases, a light location. Lighting 
fund ons can t>c 3cfincd as any combination of these coordinates. 

[0044] in ihu uiample embodiment, the achromatic parameter outputted by lighting function 302 is processed by a 
te*tunng function 306 as shown in Figure 7. At a very simple level, texturing an object means "glueing" an image onto 
that object In more octail. texturing generally works by modifying the values used in lighting function 302. For example, 

so m the tyoicai case a lighting function 302 is used to determine the color and illumination of a polygon surface, and a 
lextunng f unci on is used to modify that color/illumination to provide an additional effect (e.g., to create the appearance 
of a brick wall cr a wood grain, to make the surface appear bumpy, mirrored or warped, etc.). In the example embodiment 
shown in Figure 7. in contrast, the output of lighting function 302 is not a color or transparency value, but is instead a 
generalized parameter (for example, a texture coordinate) for texturing function 306. The texturing function develops 

55 color and/or opacity information used to modify (e.g., blend) with a primitive color and/or opacity for display on display 
device 66 

[0045] Figure 8A shows an example texture function 306. In this example, the lighting function 302 produces an 
achromatic output parameter S that parameterizes the example texture function 306. In this Figure 8A example, the 
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example texture function 306 selects one of three colors (C1 , C2, C3) or opacities depending upon the value o pa- 
rameter S. Thus, the particular color or opacity outputted by texture function 306 is determined as a function of the 
parameter S outputted by lighting function 302. Because lighting function 302 is providing parameter SUhe selection 
of which color or opacity outputted by texture function 306 can depend on any of various factors used by the lighting 
5 function calculation, including for example: 

• distance, 

• attenuation, 

• angle, 
10 • vector, 

• cosine, 

• polynomial, 

• light source type, 

• other coefficient. 

rO0461 While texture function 306 may be implemented in a variety of different ways, a cost-effective approach is to 
store the texture function 306 output values in a texture lookup table or map and to access those values using texture 
coordinates Rgure 8B shows an example one-dimensional texture map 308 indexed by lighting function 302 output 
parameter S An advantage of using aconventional texture mapping function in theexample embodiment is thattexture 
20 mapping hardware or other functionality available for general purpose texturing can also be used to implement texture 
function 306 in cooperation with lighting function 302. i n thi« 
r00471 Figure 9 shows a more detailed example including a two-dimensional texture mapping operation 306. In this 
example, a lighting calculation 302 is performed based on an identification of vertices and lighting definitions The 
output of lighting calculation 302 in the example embodiment comprises per-vertex colors (e.g., red, green, blue) and/ 
25 or transparency (i.e.. alpha). The example embodiment typically uses these lighting calculation 302 color outputs for 
Gouraud shading of a polygon surface. However, in this mode of operation, one of the color channels (e.g., blue) is 
discarded, and the other two color channels (i.e.. red, green) are converted into texture coordinates s. t using a con- 
version operation 308. The texture coordinates s, t are applied to one or more texture mapping operations 306a. 306b. 
etc to provide color/transparency output texels. Blending operation 602 may blend these texels with .surface color 
30 information (which may be derived using conventional shading techniques based on the same or different lighting 
calculation) to provide shaded, textured polygons for display. . 
r00481 In the example embodiment, texture mapping operation 306 provides two-dimensional texture mapping as 
shown in Figure 10A. In this example, the t texture coordinate is generated based on the green color channe output 
of lighting calculation 302. and is used to select one of n one-dimensional texture maps within a two-dimensional texture 
as map 31 0 The other texture coordinate s is developed based on the red color channel output of lighting calculation 
302 and is used to select a particular texel within the one-dimensional texture selected by the t coordinate. Of course, 
the s texture coordinate could select the 1-D map and the t texture coordinate could select a particular texel in other 
implementations, and/or different colors and/or opacities could be used to generate the different texture coordinates. 
Three texture coordinates could be used to select texels in a 3D texture if desired. 
40 r0049] Figure 1 0B is an illustrative example of a two-dimensional texture map 31 0 comprising a number of one- 
dimensional texture maps 308. The particular two-dimensional texture map shown in Figure 1 0B is particularly suitable 
for cartoon lighting effects. The example shown includes a number of one-dimensional texture maps including four 
maps 308(1) ... 308(4) each comprising two different kinds of texels (e.g.. purple texels and blue texels). One of the 
texture coordinates (e.g., t) selects between these different texture maps and the other texture coordinate (e.g., s) 
selects a particulartexel (i.e.. blue or purple). The various 1 Dtexture maps 308(1) ... 308(4) provide different mappings 
between the texture coordinates and blue or purple texels to provide different brush strokes or other effects. 
[0050] As another example, the 1 D texture map 308(6) shown in Figure 1 0B includes four different types of texels 
(yellow orange red and brown). These different colors could be used to provide bold cartoon-like lighting effects where, 
for example the angle a directional light makes with an object orthe distance of an object from a light source determines 
so the color resulting from the output of texture mapping operation 306. Such visualization can have a variety of interesting 
applications - especially in non-photorealistic real time rendering such as dynamically-generated cartoon animation. 
For example, it is possible to define a virtual cartoon light which lights up an object. The object's rendered visualization 
becomes dependent on vertex position, the local cartoon light position and other factors the lighting calculation 302 
takes into account (e.g.. specular or diffuse computation, distance attenuation, etc.). In one example, it is possible to 
55 set the red color channel to zero and allow the lighting calculation 302 to compute the green channel to specify a 
particular texel value within a 1 D texture defining a set of brush strokes. The material color main processor 1 1 0 typically 
can app* to lighting calculation 302 can be used to specify which 1 D texture to select within a 2D texture map. Lighting 
calculation 302 calculates which brush stroke to select on a vertex-by-vertex basis at no extra cost beyond supplying 
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one index per vertex. 

[0051] While the example shown in Figure 9 is particularly useful for cartoon lighting, it can also be used for many 
other applications. As one example, lighting function 302 can be used to calculate a shadow volume or surface. Lighting 
calculation 302 based on a given vertex could generate a shadow volume defined at texture coordinates used for the 
texture mapping operation 306. Many other applications are possible. For example, one interesting application relates 
to projective textures. An undesirable property of projective textures is that they typically project forward and backward 
from the camera. The techniques disclosed herein can provide projective texture coordinate generation based on a 
lighting function which provides attenuation (e.g., to eliminate backwards facing lighting) and/or distance attenuation 
(e.g., to attenuate the projective texture based on how far it is projected - just as you might see when using a real slide 
projector to project an image. Such projective texturing in combination with the achromatic lighting function described 
herein can produce many interesting images and imaging effects. 

[0052] A conversion operation 306 as shown in Figure 9 may not be necessary in all implementations. In the example 
embodiment, lighting calculation 302 generates an integer output that conversion block 308 converts into a floating 
point representation suitable for texture coordinates used in the following texture mapping operation 306. However, 
such integer-to-floating point conversion would not be necessary in other implementations, or other implementations 
could use different types of conversions as desired. 

[0053] In the example embodiment shown in Figure 9, lighting calculation 302 need not calculate both s and t texture 
coordinates. Since only one texture coordinate is used as a parameter in the example embodiment to select which 
particular texel was in a one-dimensional texture map should be applied to a primitive surface, the preferred embodi- 
ment preferably calculates that texture coordinate (or in intermediate valuef rom which that texture coordinate is derived) 
using lighting calculation 302. However, depending on the application, it might be desirable for the application program 
as opposed to lighting calculation 302 to specify another texture coordinate used to select (in this example embodiment) 
between plural one-dimensional textures 308. As one example, the application program running on main processor 
1 1 0 can specify a value for any or all of the color channel outputs of lighting calculation 302 via the lighting definitions 
applied to the lighting calculation input. In some applications, it may be desirable for the main processor 11 0 to specify 
the contents of, for example, the green color channel and thus the particular one-dimensional texture used in the texture 
mapping operation 306. This provides additional application programmer control while still allowing the lighting calcu- 
lation 302 to dynamically generate the s texture coordinate based on the variables lighting calculation unit 302 evalu- 
ates. Floating point values the main processor 110 sends to transform unit 300 can be truncated to RGB8 to allow 
calculations to occur in higher precision. 

[0054] In the example embodiment, there is no reason why lighting calculation 302 cannot produce a negative output 
value. In the example shown in Figure 9, this corresponds to backlighting an object. Thus, it is possible to have negative 
or backlit cartoon lighting in the example embodiment. This could be useful to provide effects where there is information 
on the backside of an object. In the preferred embodiment, the lighting unit always outputs a positive color (value). The 
preferred embodiment supports a negative type of lighting calculation, but it up to the application to add a scale and/ 
or a bias so that the final value ends up being positive. For example, the output of the lighting calculation could be 
mapped from -1 to 0 and from +1 to 1 before being converted to a texture coordinate(s). The example embodiment 
does not clamp negative values, but simply maps them into positive numerical values - with the application being careful 
to ensure that these positive values are interpreted appropriately. Of course, other implementations could support 
negative lighting values directly if desired. 

[0055] Texture mapping operation 306 and blending operation 602 shown in Figure 9 can be arbitrarily complex. For 
example, it is possible to blend with alpha. As another example, it will be possible to use two separate color channels 
outputted by lighting calculation 302 fortwo different texture mapping operations which could then be blended together 
by blender 602. Since texture mapper 500 and texture environment unit 600 in the example embodiment are both multi- 
task/multi-stage operations, a sequence of direct/indirect operations can be provided based on the output of lighting 
calculation 302 to provide a variety of interesting and complicated effects. 

Example Lighting Pipeline Implementation 

[0056] Figure 11 shows an example block diagram of lighting calculation 302. In this example, lighting calculation 
302 is performed by transform unit 300 in response to information received from command processor 200. This infor- 
mation can come from a variety of sources including main processor 110 and main memory 112 (see Figure 4). 
[0057] In the example embodiment, the transform unit 300 includes a master control section 320, a lighting compu- 
tation pipeline 322, an accumulator 324 and - for purposes of texture generation, an integer-to-floating point converter 
308. Master controller 320 receives lighting definitions and vertex definitions from command processor 200 and, after 
appropriate storage/buff ering, provides associated information to the lighting computation pipeline 322. Lighting pipe- 
line 322 performs a lighting computation in the following basic form: 
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1=0 

5 where C n defines the output of the lighting calculation pipeline, C materta , defines the material color, A,, defines the 
ambient color, L(c) defines the lighting diffuse or specular component, and A defines distance attenuation. This calcu- 
lation computes an RGB triplet since the example embodiment lighting calculation pipeline 322 can perform two such 
lighting calculations in parallel. Because of this parallel computation feature, one of the lighting computations can be 
used for achromatic lighting effects for an object and the other lighting computation can be used for chromatic lighting 

10 effects on the same object. The parallel computation feature makes effects such as cartoon lighting "free" in the sense 
that it takes no more processing time to generate a shaded polygon surface with cartoon lighting effects than it does 
to generate the shaded polygon surface without such cartoon lighting effects. In the example embodiment, the C n value 
generated by lighting computation pipeline 322 can be positive or negative - with negative lighting allowing backlit and 
other interesting effects. 

is [0058] In the example embodiment, a C n output of lighting computation pipeline 322 is accumulated by a integer 
accumulator 324. The accumulated output is, in the example embodiment, converted into floating point by conversion 
block 308 and provided as texture coordinates to texture unit 502 for texture mapping operations. The example em- 
bodiment can provide texture filtering as part of texture mapping operation 306. The application programmer should 
be careful about the lexlure filtering mode chosen when using lighting calculation 302 to generate texture coordinates. 

20 Problems may result due to the fact that the s and t axes in the example embodiment are used for independent factors, 
but certain types of texture filtering apply to both axes simultaneously. One work around is to duplicate, within the 
texture map each entry along the t axis in order to ensure that interpolation between adjacent t values has no effect 
or the final oUput. Thus, one-dimensional texture filtering for adjacent values of t will be identical. Mipmap filtering 
with multiple levels of details can also take place, but this may also act to reduce the number of 1 D textures within a 
giver 2D texture map. 

[0059) m the example embodiment, another complication results from the method of converting the lighting calcula- 
te n 302 ccior value into texture coordinates. The color value produced by lighting calculation 302 in the example 
,rr P irmrniHi»on »< *n 8-bit integer in the range of 0-255. Convert block 308 converts this integer value into a floating 
pr..n! mmtxv hy divxlmg it by 255. However, the value is converted into a texture coordinate by multiplying it by the 
io \ct\wc si/c »n the example embodiment. This process means that the application programmer should pay careful 
a! cnt.on to the texture coordinate for choosing the 1 D texture. Assuming a texture size of 256 and GX_NEAR texture 
facing tnti w»n rnap m the following manner: 



Color Value 


Converted texture coordinate 


Nearest value 


0 


0 


0 


64 


64.251 


64 


127 


127.498 


127 


128 


128.502 


129 


192 


192.753 


193 


254 


254.996 


255 


255 


256 


255 



[0060] Due to no conversion process, coordinate value 128 is skipped, and color values 254 and 255 map to the 
same ccordmatc value If we assume a texture size of 256 and GX_LINEAR filtering, we have the following mappings: 



so 



Color Value 


Converted texture coordinate 


Coords looked up 


0 


-0.5 


0,0 


1 


0.504 


0, 1 


2 


1.508 


1,2 


3 


2.512 


2,3 


4 


3.516 


3,4 
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Color Value 


Converted texture coordinate 


Coords looked up 


126 


125.994 


125, 126 


127 


126.998 




128 


128.002 


128,129 


253 


253,492 


253, 254 


254 


254.496 


254, 255 


255 


255.5 


255, 255 



100611 It is safe to use n*2 to convert a table ID into a color value in the example implementation. However, the 1D 
, 5 extures should be stored in a non-straightforward manner within the 2D texture. The table for n=0 should be stored 
at coordinate 0 (only), tables for n=1 to n=63 should be stored at n*2-1 and n*2, and tables for n=64 to n=127 should 
be Stored at n'2 and n*2 + 1 . Coordinate 1 27 may be left empty since it will not normally be accessed ,n th,s parfcular 
implementation. Other implementations might avoid this issue altogether, or present different convers.on .ssues. 

so Example More Detailed Transform Unit 300 Description 

rO0621 Figures 1 2-20 show a further example, more detailed embodiment of transform unit 300 including a lighting 
pipeline used for lighting calculation 302. In the example embodiment of system 50. transform unit 300 supports l.ght.ng 
in hardware as a per-vertex calculation. This means that a color (RGB) value can be computed for every ht vertex ^ and 
25 thatthesecolorscanbelinearlyintemolatedov^^ 

unit 300 in this example embodiment has full support for diffuse local spotlights, and also has some support for mf,n,te 

ro P OM] ar TSnsform unit 300 in this example embodiment supports diffuse attenuation. This means that the front of the 
object 'can bebrighter than the sides, and the back darkest Transform unit 300 supports vertexnomialsso astoprovde 
30 diffuse attenuation. For each vertex, the vertex normal (N) is compared against the vector between the vertex and the 

light position. ^ embodjment of transform unit 300 also supports local lights. Local lights have a position within 
the world and possibly also a direction. Each light is defined to have a position. Using the position of each vertex and 
the position the light, transform unit 300 can perform per-vertex distance attenuation. This means you can make the 
3S brightness of the light shining on an object decrease as the object moves away from the light. 

r00651 Transform unit 300 in the example embodiment also supports directional lighting. Support ranges non-d.rec- 
ional ights, to subtle directional effects, to highly directional spotlights. These effects are supported by angle , atenu- 
ation.Thus, vertices directly "in the beam" of the light can be made brighterthan vert.cesouts.de of the beam or behmd 

40 [0066] ht Local diffuse lights can be both distance-attenuated and angle-attenuated. By programming the proper lighting 
equation, it is possible for an application programmer to obtain attenuation values as an output color or alpha (or, .n 

the case of texture coordinate generation, as a texture coordinate). 

00671 in the example implementation, transform unit supports eight physical lights. The application programmer can 
describe the attenuation parameters, position, direction and color of each light. The application programmer can also 

4S control up to four physical color channels that accumulate the result of the lighting equation. By assoc.at.ng hghts wrth 
channel .the application programmer can choose to sum the effect of multiple lights per vertex, or ^.nethem later 
in the texture environment unit 600. The number of channels available to the texture env.ronment unrt 600 .s set by 
the application programmer. In some cases (e.g.. when using a color channel to generate texture "orates). a JJ* 
channel is computed but not outputted as a color or opacity. As discussed above, transform unit 300 .s p.pel.ned so 

50 ascalculatetwocolorchannelssimultaneously.butmayprovideonlyonecolorchanneldirectlytote^ 

unit 600 for blending. The other color channel can be provided in the form of texture coordinates to texture unrt 500^ 
[0068] Each color channel enables attenuation in the selection of color source. A light mask assoca es up to e.ght 
lights with the channel. See Figure 12 channel which shows example association of up to e.ght drfferent l.ghts w.th any 
of two color channels and two alpha channels to provide two independent outputs one of wh«h can be converted to 

55 So69] C A?show e n in Figure 12. transform unit 300 in the example embodiment generates two RGBA colors (color 0 
and color 1). Each output color has two lighting functions: one for RGB and one for alpha, for a total of four l.ght.ng 
functions per polygon per vertex. Four such lights allow a variety of lighting effects such as. for example, .n multrtex- 
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o" the eight tgltt retained b, traoslodr, uM MO The e, u a»<^ .J*to d« ^ P ^ but it is 

data pad. ia deeded SSSSSEi td, te^b^ed KjMn, ««h the ear* date 

Exam ple Lig hting Calculation 

10070] Examp.e lighting equations performed by transform unit 300 are as foHows: 

R 

xLightFunc G 
C = \ d B 



25 



30 



Material, 



,ifC = Color OKt ,Color lt 



Material c W LightFuncMl If C - Color >^ ' Color ^ 
Material, = MaterialSrc e = REGISTER* VertexColor e : Materia/ Reg e 

f 1.0, if LightFuncEnable c = FALSE 
LightFunc c = | /Wmw ^ j;/r LightFuncE nable c = TRUE 



35 



40 



45 



50 



55 



Ambc = (AmbSrc,, = flEG/ST£fl ? VertexCotor, . Ambfenf Reg) 
l0 071, in the example embodiment, the -te^ 

of a vertex color from command processor ^ processor 110l so that the result .s one of 

mination from the additional lights, based on software ™ color. It is also possible if desired for ma,n 

2 vertex colors, and set the ambient source reg.s er to use that ^ex ^ computatlon 

^or110tooomputeanyora,.o^^^ 

outputs in the form of vertex colors to transform jnrtSWOW ^ texture mappjng 

may pass the computed texture coordmates to texture unit 500 to p jp ^ 3Q0 uncnanged The 

P0721 DisabHng the "LightFunc" P"j££^ program software control, which of a 

can be used to allow main processor 110 to d ^«y£e«. bas*d ^ PP achromatic „ ghtlng (unctlon out put 
plurality 1 D textures to use in a texture mapping °P^°"J^ acn lignting func tion. The sum of the per-l.ght rtlu- 
raowi Any or all of the available eight lights can be enabled m each ingn S I t before adding the 

SL^pedtoM.1]in the example^ 
global ambterttemi.8inc.tfie total Hlum.^ 

r^»d9eldh.«elu«eeel»cod*,n^«*^R^*» ouster tit. che«o.loecW ..p«=u* 

«nMdimeat. Fo, eaamp.e. it » po»«e '^^JT^tTZu. environment unit 600 multiply the <Mu» color 

^r^o^^^ 
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20 



undamped Undamped dot products allow light-based texture generation to control illumination for 180°. Since the 
illumination will be clamped in the example embodiment, signed lighting functions may be scaled and biased appro- 
priately using color c and amb c . The example embodiment provides three example diffuse attenuation f unct.ons a lighting 
equation can use: 



DiffuseAtten c (i) = 



1.0, if DiffAttenSelect c = NONE 
N ■ Z, , if DijfAttenSelect c = SIGNED (if SPOTLIGHT only) 
Clamp(KN ■ 1, ), if DiffAttenSelect c = CLAMPiif SPOTLIGHT only) 



100761 The angle attenuation logic in the example embodiment computes a second-order polynomial based on the 
dot product of the light-to-vertex vector and the light-direction vector. A sharp fall off is achieved by extrapolating the 
souared and linear terms. Clamping is used to avoid negative values produced by extrapolation for angles outs.de of 
a spotlight angle. Range attenuation can be performed by the inverse of another second-order polynomial. The distance 
value d is the length of the vector from the vertex to the light position. A light equation with only distance attenuation 
can be used for texture-based lights to simulate the distance-based illumination falloff of projected or other textures. 
r00771 This same logic can be used to approximate common specular attenuation , (N Hf for a parallel light source. 
The light-to-vertex and light-direction vectors may be replaced with the normal and half-angle vectors respectively. 
Attenuation can be defeated in a lighting function to permit non-attenuated point light (e.g., omni-direction) sources to 
be used in both a diffuse and specular equation. In this example, the lights angle attenuation coefficients may be used 
for the specular equation, and attenuation is turned off in the diffuse equation. Specular and diffuse equations in the 
example embodiment are combined in texture environmer 600 as opposed to within transform unit 300 in the example 
25 embodiment, but other implementations are possible. 

[0078] Further details of the example attenuation function are as follows: 

C/amp0(a 2 AAff c (/) 2 + A,. AAtt e {i) + Aq) 

Atten, = AttenEnable c ? '-z 77; — • 10 

30 e ^(O+K^IO+Ko,. 

. _ pV* • L > 0 ? clamp0(N -H,): 0, if AttenSelect c = SPECULAR 
3S AAu c (i)-\ clampfKL-L^if AttenSelect c = SPOTLIGHT 



40 



45 



d c (0 = 



N-L>01 clamp0(N • H s ) : 0, if AttenSelect c = SPECULAR 
VZ~L~ if : AttenSelect c = SPOTLIGHT 



Example Transform Unit 300 Implementation Block Diagram 

[0079] Figure 13 is a block diagram of an example implementation of transform unit 300 of system 50. Transform 
unit 300 in this example embodiment includes three main sections: 

• top-of-pipeline section 330 , 
light section 332, 

so ♦ bottom-of-pipeline section 334. 

rOOSOl The top^of-pipeline section 330 in the example embodiment includes light section 332, a context matrix store 
336 an input FIFO buffer 338, a dot product unit 340, a projection block 342, a texture dot two block 346, a cnpp.ng 
detector 348, and a bypass FIFO block 350. In the example embodiment, top-of-pipeline (TOP) section 330 performs 
55 the following example functions: 

• vertex transform (3 dot products), 

• Normal transform (3 dot products), 
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• texture transform (2 or 3 dot products for texture), 

• projection transform (simplified 3 dot products); and 

light section 332 performs the following example color channel functions: 

• color channel 0 diffuse computation (1 dot product NL), 

• color channel 0 diffuse computation (1 dot product L 2 per light), 

• color channel 0 diffuse computation (1 dot product N 2 ). 

[0081] in addition, the input FIFO receives per-vertex vertex descriptors specifying, for example, the following Infor- 
mation: 

• geometry information XYZ, 

• Normal vector information N x , N y , N z , 

• RGB A color 0 per vertex, 

• RGB A color 1 per vertex, 

• Binormal vector T x , T y , T z , 

• Binormal vector B x ' By, B z 

• Texture 0 data T 0 , 

• Texture 1 to n data S n> T n . 

r0082] Appropriate per-vertex information is provided to light section 332 to enable the lighting co ^ X ^ m ^ 
[OoS] Ught section 332 in the example embodiment shown in Figure 13 includes a lighting parameters memory 

KLaJu. holds all of the various lighting information (e.g., light vectors, light parameters etc ). Both gHtaM 

JSL. are stored in this memory in the example embodiment. In the example * m *>^ 

w^r'n 32-bits, but only the twenty most significant bits are kept. Each location is three words w.de 

word wrle 'size of three words in the example embodiment. The following shows example contents of l.ght parameter 

memory 352: 
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Register Address 


Definition 


Configuration 


0/0600 


Reserved 




0x0601 


Reserved 




0x0602 


Reserved 




0x0603 


LightO 


32b: RGBA (8b/comp) 


0x0604 


LightOAO 


20b: cos atten. Aq 


0x0605 


LightOAl 


20b: cos atten. A 1 


0x0606 


LightOA2 


20b: cos atten. A2 


0x0607 


LightOKO 


20b: dist atten. Kq 


0x0608 


LightOKI 


20b: dist atten. 


0x0609 


LightOK2 


20b: dist atten. Kg 


0x060a 


LightO Lpx 


20b: x light pos, or inf Idir x 


Ox060b 


LightOLpy 


20b: y light pos, or inf Idiry y 


Ox060c 


LightOLpz 


20b: z light pos, or inf Idir z 


0x060d 


LightODx/Hx 


20b: light dir x, or 1/2 angle x 


0x060e 


LightODy/Hy 


20b: light dir y, or 1/2 angle y 


0x060f 


LightODz/Hz 


20b: light dir z, or 1/2 angle z 


! 0x061 0-0x067f 


Light(n)data 


See LightO data 
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Register Address 


Definition 


Configuration 


0x0680-0x07ff 


Not used 


Reserved 



[0085] An overview of the light section 332 of the example embodiment: is shown in Figure 14. Briefly, the light 
section 332 performs the following local lighting computations: 



10 



15 



= Material* 



Mr 
Mg 
Mb 



20 



(Ambient 0 



Ra 
Ga 
Ba 



CosAtFunc 0 clamp ( Norma i . Ught ) x Diffuse, 
DistAtFunc* 



Rd 
Gd 
Bd 
L 0.0j 



25 This requires a local light vector computation per vertex: 
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Lx 

Light . = Normalized (Light Pos} Ly 

; U 



Xh 

- EyeSpaceVertej\ Yh 
Zh 



after which, we need to compute: 

DiffuseAtten 0 = Conditional_damp _ to_0(Light f ♦ EyeSpaceNormaf) 

[0086] Thus, the diffuse attenuation calculation requires the light vector and the eye-space Normal. Clamping to 0 
may be conditional on an internal flag (e.g. , it can be clamped to 1 .0 or not clamped at all) in the example implementation . 
It is possible to allow diffuse lights to have negative dot products. A lighting dot product unit can compute the eye- 
space Normal while the transform dot product unit computes the geometry eye-space conversion. Then, a lighting dot 
product unit can compute the N-L, L 2 and N 2 dot products. After this, the example embodiment normalizes the results 
to provide normalized light vector Normal information. After normalization, the intermediate results of the normalization 
(e.g., distance squared and distance and cosine N-L) are used to compute the attenuation equations as well as the 
normalization factors. Then, the light ambient vector is multiplied. The resulting triplet is the per-light attenuated diffuse 
component. This is converted to 2's complement integer, and the resulting three values are accumulated in an integer 
accumulator. This accumulator adds the ambient terms and any other diffuse terms from other lights. The final sum is 
then the per-vertex color (in the example embodiment, an 8-bit RGB format clamped to 0 to 255). 
[0087] Figure 15 shows an example diagram of the vector dot/Madd block 357 shown in Figure 14. If the same dot 
product unit is used to compute the transform N and all other dot products, then the performances may become some- 
what degraded and the scheduling of light becomes difficult since each light needs to re-use the same data path element 
multiple times. This may lead to complex control issues. To simplify the design, we can implement a second limited 
dot product unit to separate the various computations. The first dot product unit may compute the transform normal 
while the other dot product unit computes the vertex transformation. A vector add may then compute the light vector 
for local lighting. The second dot product may compute N 2 L 2 , N-L and N-H (for specular lights). This can be achieved 
in the example embodiment in a fully pipelined way with no feedbacks. See Figure 15. 

[0088] Figure 16 shows an example implementation of the normalizer 360 shown in Figure 14. Once the lighting 
vector values are computed, the example embodiment normalizes the results and computes attenuation. Example 
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embodiment normalizer 360 accepts the following inputs: 

• Cosine attenuation: L-Dir, 1/sqrt (L) 

• Distance attenuation: L 2 , L 
5 • Diffuse factor: N-L, N 2 , L 2 , 

and computes distance attenuation using the following step performed by example normalizer 360 shown in Figure 1 6: 

1 . Compute K 2 d 2 

10 2. Compute K 2 d 2 + K0 

3. Compute d 

4. Compute K.,d 

5. Compute D 2 D 2 + + KO 

6. Compute 1/(K 2 d 2 + K,d + KO) 

75 

[0089] Figure 1 7 shows an example distance attenuation unit 362. The example distance attenuator implementation 
362 computes cosine attenuation using the following example steps: 

20 1 . Compute Cos = ClampO(L.Ldir) 

2. Compute Cos 2 

3. Compute A^os 2 

4. Compute A 1 Cos 

5. Compute A 1 Cos + AO 

25 6. Compute A 2 Cos 2 + A 1 Cos + AO 

7. Compute Clamp_0(A+2+Cos 2 + A^os + AO) 

[0090] Figure 1 8 shows an example implementation of light scaler 364 that computes the following: 

30 • 1/sqrt (N 2 ) 

• 1/sqrt (L 2 ) 

• N.L(sqrt(N 2 )xsqrt(L 2 )). 

[0091] Some of the units (e.g., 1/sqrt and some of the multipliers) can be shared among the various data path im- 
35 plementations shown in Figures 15-1 8. Thus, an implementation might approximately require on the order of eighteen 
multipliers and ten adders. Inversion and 1/sqrt can be performed using a table lookup or a simple one-pass Newton- 
Raphson interpolator or some other pipeline interpolator. Alpha and specular writing computations do not require any 
additional hardware in the example embodiment since they are just changes in the lighting equation. 
[0092] Figure 1 9 shows an example integer accumulator 336 implementation. When a new attribute arrives for each 
40 color, that color is accumulated. Once all lights are accumulated for a color, and the ambient is added (e.g., from the 
vertex color FIFO or from a register) then the material color is multiplied. The final RGB/A color is then accumulated 
into an accumulation/format register by construction of the final color and texture generation. Once the color/texture 
is computed, it is then written into an output FIFO. Control may follow these general guidelines: 

45 



50 



55 



16 



^SOOCID: <EP 1 189173A2_I_> 



EP 1 189173 A2 



10 



15 



20 



25 



40 



If (new attribute == new light for color X) 

Accumulate new light into color X 
Increment number of lights for color X 

End 

If (number of lights for color X is maximum) 
Transfer color to multiplier 
Perform material multiply 

End 

If (color X is in multiply state) 

Accumulate color X first 

End 

If (Accumulation of color X is complete (RGBX or AXX or RGB A)) 
Format color X for color, if color enabled 

Format color X for texture, if texture enabled and color disabled or 
color already loaded 

Load output fifo with formatted data, increment color/texture count 

End 

If (color Cv>u:u anJ texture count at maximum) 
W rite data to BOP 
fVpfilo 

End 



[0093] Figure ?0 +n ri^mpio stage transition diagram used to control light pipeline 332 in the example em- 

30 bodiment. Arbiter logc occkjos trc sequence of events that it issued into the light data path. The example embodiment 
arbiter can only isslc h new event every four or eight cycles, depending on the event. The list of possible events 
includes: 

• light computation for n specific color/alpha, 
35 • bump map computation 

[0094] For the abeve events tne arbiter drops an attribute into the control pipeline every 4/8 cycles. Each of these 
attribute carries the execution instructions for the event into the light pipeline 332. At the end of the pipeline, the at- 
tributes are used to increment local counts which are used to determine if the colors/textures are complete. 



Other Example Compatible Implementations 



[0095] Certain of the above-described system components 50 could be implemented as other than the home video 
game console configuration described above. For example, one could run graphics application or other software written 
45 for system 50 on a platform with a different configuration that emulates system 50 or is otherwise compatible with it. If 
the other platform can successfully emulate, simulate and/or provide some or all of the hardware and software resources 
of system 50, then the other platform will be able to successfully execute the software. 

[0096] As one example, an emulator may provide a hardware and/or software configuration (platform) that is different 
from the hardware and/or software configuration (platform) of system 50. The emulator system might include software 
so and/or hardware components that emulate or simulate some or all of hardware and/or software components of the 
system for which the application software was written. For example, the emulator system could comprise a general 
purpose digital computer such as a personal computer, which executes a software emulator program that simulates 
the hardware and/or firmware of system 50. 

[0097] Some general purpose digital computers (e.g., IBM or Macintosh personal computers and compatibles) are 
55 now equipped with 3D graphics cards that provide 3D graphics pipelines compliant with DirectX or other standard 3D 
graphics command APIs. They may also be equipped with stereophonic sound cards that provide high quality stereo- 
phonic sound based on a standard set of sound commands. Such multimedia-hardware-equipped personal computers 
running emulator software may have sufficient performance to approximate the graphics and sound performance of 
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20 



rendering in response to 3D graphics commands issued based on a standard 3D graphics application programmer 
interface such as Microsoft's DirectX 7.0 or other version. A set of stereo loudspeakers 1237 is also connected to 
system bus 1207 via a sound generating interface such as a conventional "sound card" providing hardware and em- 
bedded software support for generating high quality stereophonic sound based on sound commands provided by bus 
5 1207. These hardware capabilities allow system 1201 to provide sufficient graphics and sound speed performance to 
play software stored in storage medium 62. 

[01 05] While the invention has been described in connection with what is presently considered to be the most practical 
and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, 
but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope 
10 of the appended claims. For example, as will be appreciated, although a particular cartoon lighting example is disclosed 
herein, the invention is not to be limited to cartoon lighting but rather, encompasses a variety of photo-realistic and 
non-photorealistic, texture-based and non-texture-based applications and effects that may be accomplished using an 
achromatic lighting parameter. 

15 

Claims 

1 . In a graphics generating system (50) of the type that defines at least one per-vertex lighting function, a method of 
gcner aling graphics images characterized by: 

using the lighting function to calculate at least one parameter other than color or opacity to be used in a 

subsequent modification of a color or opacity; and 

rendering an image based at least in part on the calculated parameter. 

2. The method as in claim 1 further characterized in that the parameter comprises at least one texture coordinate. 

3 The method as n any one of the preceding claims further characterized in that the lighting function calculates 
***r. fcr^st one parameter based at least in part on distance attenuation between a vertex and a light source. 

jo 4 The method as m any one of the preceding claims further characterized in that said lighting function calculates 
s,«-c ht *e*st one parameter based at least in part on the angle between the light source to vertex direction and 

f>e surtr«:c normal 

5 The metnod as m any one of the preceding claims further characterized in that said lighting function calculates 
J* sh.c Ht icr-st one parameter based at least in part on a vertex vector position. 

6 Tne m C !hod as n any one of the preceding claims further characterized in that said lighting function defines a 
t jnction tused upon surface position, surface orientation and the position of at least one light. 

+e 7 The method as m any one of the preceding claims further characterized in that said lighting function calculates 
n neqnt»vc pHMmctcr for back lighting. 

8 the method as m any one of the preceding claims further characterized in that said lighting function can use 
ciHusc or specuar lighting. 

9. The method as in any one of the preceding claims further characterized in that the rendering step comprises 
ycrioratiny ri texture for a surface based at least in part on said parameter. 

10. The method as ?n any one of the preceding claims further characterized in that said rendering step comprises 
50 texture mapping using a one-dimensional texture indexed by said at least one parameter. 

11. The method of any of the preceding claims further characterized in that the method further includes: 

using a lighting function to generate at least one color or opacity value; 
55 converting said color opacity value to at least one texture coordinate; 

using said texture coordinate in at least one texture mapping operation; and 

using the results of said texture mapping operation to modify the color or opacity of at least one visible surface 
in a dynamically generated cartoon image. 
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12. The method as in claim 11 further characterized in that said texture mapping operation comprises mapping a 
one-dimensional texture in response to said texture coordinate. 

13. The method as in any one of the preceding claims 11-12 further characterized in that said texture mapping corn- 
5 prises mapping brush strokes to dynamic lighting computation outputs. 

14. The method as in any one of the preceding claims 11 -13 further characterized in that said texture coordinate can 
range negatively to define cartoon backlighting. 

10 15. The method as in any one of the preceding claims further characterized in that said lighting function defines a 
first texture coordinate for said texture mapping and a second texture coordinate for said texture mapping is derived 
from a source other than said lighting function. 

16. The method as in any one of the preceding claims further characterized in that said lighting function comprises 
15 a diffuse lighting function. 

17. The method as in any one of the preceding claims further characterized in that said lighting function comprises 
a specular lighting function. 

20 18. The method as in any one of the preceding claims further characterized in that said lighting function comprises 
a distance-attenuated lighting function. 

19. The method as in any one of the preceding claims further characterized in that said lighting function comprises 
a spotlight lighting function. 

25 

20. The method as in any one of the preceding claims further characterized in that the generated parameters can 
be either host computed or computed using the lighting function, as required. 

21 . The method as in any one of the preceding claims further characterized in that one generated parameter is used 
30 to select a texel within a 1 D texture and a second parameter is used to select which 1 D texture to use. 

22. In a graphics system (50) comprising a lighting data pipeline (300) comprising at least first and second channels, 
said lighting data pipeline (300) receiving per-vertex information and lighting definitions, and calculating lit vertex 
parameters in response to said per-vertex and lighting definitions; 

35 the system (50) further characterized by: 

a texture unit (500) coupled to said lighting data pipeline (300), said texture unit (500) performing at least one 
texture mapping operation using at least one of said lighting data pipeline (300) outputs as at least one texture 
coordinate; and 

40 a blender (700) coupled to said lighting data pipeline (300) and said texture unit (150), said blender (700) 

blending chromatic and/or opacity information obtained from said lighting data pipeline (300) with texels ob- 
tained from said texture unit (500)to provide a rendered image. 

23. The system as in claim 22 further characterized in that the lighting data pipeline outputs comprise at least one 
45 texture coordinate. 

24. The system as in any one of the preceding claims 22-23 further characterized in that the lighting data pipeline 
output is calculated based at least in part on distance attenuation between a vertex and a light source. 

50 25. The system as in any one of the preceding claims 22-24 further characterized in that said lighting data pipeline 
output is calculated based at least in part on the angle between the light source to vertex direction and the surface 
normal. 

26. The system as in any one of the preceding claims 22-25 further characterized in that said lighting data pipeline 
55 output is calculated based at least in part on a vertex vector position. 

27. The system as in any one of the preceding claims 22-26 further characterized in that said lighting data pipeline 
output defines a function based upon surface position, surface orientation and the position of at least one light. 
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28. The system as in any one of the preceding claims 22-27 further characterized in that said lighting data pipeline 
output is calculated in the form of a negative parameter for back lighting. 

29. The system as in any one of the preceding claims 22-28 further characterized in that said lighting data pipeline 
s outputs can be for diffuse or specular lighting. 

30. The system as in any one of the preceding claims 22-29 further characterized in that said texture unit (1 50) uses 
a one-dimensional texture indexed by said at least one parameter. 

io 31. The system as in any one of the preceding claims 22-30 further characterized in that said texture unit (500) maps 
brush strokes to dynamic lighting computation outputs. 

32. The system as in any one of the preceding claims 22-31 further characterized in that said texture coordinate can 
range negatively to define cartoon backlighting. 

15 

33. The system as in any one of the preceding claims 22-32 further characterized in that said lighting output defines 
a first texture coordinate for said texture mapping and a second texture coordinate for said texture mapper (500) 
is derived from a source other than said lighting output. 

20 34. The system as in any one of the preceding claims 22-33 further characterized in that said lighting output comprises 
a diffuse lighting function. 

35. The system as in any one of the preceding claims 22-34 further characterized in that said lighting output comprises 
a specular lighting function. 

25 

36. The system as in any one of the preceding claims 22-35 further characterized in that said lighting output comprises 
a distance-attenuated lighting function. 

37. The system as in any one of the preceding claims 22-36 further characterized in that said lighting output comprises 
30 a spotlight lighting function. 



35 
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